Vibe Coding 是 Andrej Karpathy 在 2025 年提出的 AI 輔助編程範式，透過自然語言與 AI 互動生成程式碼，強調直覺與創意而非技術細節。

其流行得益於 AI 技術進步、門檻降低和社群推廣，從早期 LLM Coding 的輔助角色，演進到以對話式創作取代鍵盤操作的革命性方式。雖然它加速了原型設計和創意實現，但也面臨程式碼品質和安全性的挑戰。

隨著 AI 編碼工具如 ChatGPT 的普及，我們能更快產出程式碼，但更重要的是，如何結合嚴謹的測試與需求驗證流程，真正落實品質保證。本文用一個簡單的函式 fun(int a, int b, int c)（判斷三角形類型）為例，來看看 Vibe Coding開發做法的演進。

規格
函式輸入三個正整數 a, b, c，代表三角形的三邊長。回傳字串代表：
• 「不是三角形」
• 「正三角形」
• 「等腰三角形」
• 「普通三角形」

階段 1：AI 根據規格直接產生程式碼與簡單測試

(1) 程式碼

public string fun(int a, int b, int c)
{
    if (a <= 0 || b <= 0 || c <= 0)
        return "不是三角形";

    if (a + b <= c || a + c <= b || b + c <= a)
        return "不是三角形";

    if (a == b && b == c)
        return "正三角形";

    if (a == b || b == c || a == c)
        return "等腰三角形";

    return "普通三角形";
}

(2) 簡易測試程式

public void TestFun()
{
    System.Diagnostics.Debug.Assert(fun(3, 3, 3) == "正三角形");
    System.Diagnostics.Debug.Assert(fun(3, 3, 4) == "等腰三角形");
    System.Diagnostics.Debug.Assert(fun(3, 4, 5) == "普通三角形");
    System.Diagnostics.Debug.Assert(fun(1, 2, 3) == "不是三角形");
}

(3) 這個階段的問題
• 測試案例不足，未涵蓋所有邊界與異常情況。
• 程式碼及測試缺少系統化設計，對需求的表達模糊。
• AI 生成程式碼靈活度高，但缺乏穩定性，稍有改動就可能大幅重寫。

階段 2：利用 TDD 先產生測試，再產生程式碼

(1) 測試程式（使用 MSTest 範例）

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public class TriangleTests
{
    [TestMethod]
    public void EquilateralTriangle()
    {
        Assert.AreEqual("正三角形", fun(5, 5, 5));
    }

    [TestMethod]
    public void IsoscelesTriangle()
    {
        Assert.AreEqual("等腰三角形", fun(5, 5, 3));
        Assert.AreEqual("等腰三角形", fun(5, 3, 5));
        Assert.AreEqual("等腰三角形", fun(3, 5, 5));
    }

    [TestMethod]
    public void ScaleneTriangle()
    {
        Assert.AreEqual("普通三角形", fun(3, 4, 5));
    }

    [TestMethod]
    public void NotTriangle()
    {
        Assert.AreEqual("不是三角形", fun(1, 2, 3));
        Assert.AreEqual("不是三角形", fun(0, 5, 5));
        Assert.AreEqual("不是三角形", fun(-1, 2, 3));
    }
}

(2) 實作程式碼

public string fun(int a, int b, int c)
{
    if (a <= 0 || b <= 0 || c <= 0)
        return "不是三角形";

    if (a + b <= c || a + c <= b || b + c <= a)
        return "不是三角形";

    if (a == b && b == c)
        return "正三角形";

    if (a == b || b == c || a == c)
        return "等腰三角形";

    return "普通三角形";
}

(3) 問題說明
• 測試先行強制開發依需求邏輯，品質提升。
• 測試語言技術性強，對非技術人員難以理解，溝通仍有限。
• 若需求大幅變動，測試及程式碼仍需頻繁調整。

階段 3：採用 Specification by Example，明確定義驗收條件

(1) 驗收條件（Gherkin 語法）

Feature: 判斷三角形類型

Scenario: 非三角形
  Given 三邊長為 1, 2, 3
  When 呼叫 fun 函式
  Then 回傳 "不是三角形"

Scenario: 正三角形
  Given 三邊長為 3, 3, 3
  When 呼叫 fun 函式
  Then 回傳 "正三角形"

Scenario: 等腰三角形
  Given 三邊長為 5, 5, 3
  When 呼叫 fun 函式
  Then 回傳 "等腰三角形"

Scenario: 普通三角形
  Given 三邊長為 3, 4, 5
  When 呼叫 fun 函式
  Then 回傳 "普通三角形"

(2) 產生的 Cucumber 測試程式（示意）

Scenario Outline: 判斷三角形
  Given 三邊長為 <a>, <b>, <c>
  When 呼叫 fun 函式
  Then 回傳 "<result>"

Examples:
  | a | b | c | result     |
  | 1 | 2 | 3 | 不是三角形 |
  | 3 | 3 | 3 | 正三角形   |
  | 5 | 5 | 3 | 等腰三角形 |
  | 3 | 4 | 5 | 普通三角形 |

(3) 問題說明
• 驗收條件用業務語言描述，跨團隊易理解，促進共識。
• 驗收條件穩定，程式重構時不易變動，減少溝通成本與維護壓力。
• 需要團隊熟悉 BDD 工具與流程，初期導入成本較高。

階段 4：加入 Decision Table Testing，全面產生測試用例

(1) 決策表範例

(2) 利用 ChatGPT 根據決策表產生測試程式碼（範例）

[TestMethod]
public void DecisionTableTests()
{
    // 不是三角形
    Assert.AreEqual("不是三角形", fun(0, 1, 1));
    Assert.AreEqual("不是三角形", fun(1, 0, 1));
    Assert.AreEqual("不是三角形", fun(1, 1, 0));
    Assert.AreEqual("不是三角形", fun(1, 2, 3)); // a+b <= c

    // 正三角形
    Assert.AreEqual("正三角形", fun(5, 5, 5));

    // 等腰三角形
    Assert.AreEqual("等腰三角形", fun(5, 5, 3));
    Assert.AreEqual("等腰三角形", fun(5, 3, 5));
    Assert.AreEqual("等腰三角形", fun(3, 5, 5));

    // 普通三角形
    Assert.AreEqual("普通三角形", fun(3, 4, 5));
}

(3) 問題說明
• 決策表完整羅列各種條件組合，避免遺漏重要測試。
• 減少測試重複與冗餘，維護更高效率。
• 使測試結構化，利於自動化與快速調整。

四階段演進總結

「Vibe Coding」：從寫程式碼到確認需求與測試的思維轉變

階段一、二的 AI 產碼雖快速，但隨著需求複雜與團隊規模擴大，僅靠「寫程式」已無法保障品質與溝通效率。

階段三與四則體現了「Vibe Coding」的本質——
開發人員的重心不再只是寫出程式碼，轉而要確認需求是什麼，並且做出完整的測試與驗收，讓軟體開發成為一種協作與共識的藝術。

唯有如此，AI 才能真正成為助力，而非隱藏風險的黑盒。

無論你現在使用哪種工具或方法，記得在 AI 快速產碼的背後，持續經營「需求明確、測試完整」的基礎，才是長久保證軟體品質的關鍵。